методичка. методичка АИС2. Архитектура информационных систем
 Скачать 4.53 Mb.
|
|
1.2. Логическое проектирование базы данных (для реляционной модели) На данном этапе структура данных изменяется в форму, которая не создает никаких трудностей при внедрении в СУБД. На данной стадии выполняются следующие действия: удаление связей типа M:N. Если в информационно-логической модели базы данных есть отношения типа M:N, их следует удалить. Для этого определяют некоторый промежуточный объект. Таким образом, связь вида M:N будет заменена двумя связями вида 1:M, которые устанавливаются вместе с вновь созданным объектом. удаление сложных связей. Сложной будет называться связь, которая существует между тремя и больше типами объектов. В случае если в информационно-логической модели существует сложная взаимосвязь, ее следует удалить с помощью промежуточного объекта. Сложное соединение заменяется необходимым количеством двоичных подключений типа 1:M, установленным с вновь созданным объектом. удаление рекурсивных связей. Рекурсивными называются такие связи, в которых объект некоторого типа будет взаимодействовать сам с собой. Если в концептуальной модели информационной системы существует сложная взаимосвязь, ее следует удалить с помощью промежуточного объекта. Сложное соединение заменяется необходимым количеством двоичных подключений типа 1:M, установленным с вновь созданным объектом. удаление связей с атрибутами. Если в информационно-логической модели имеются связи, которые имеют собственные атрибуты, то их требуется преобразовать с помощью создания нового объекта. удаление множественных атрибутов. Если в информационно-логической модели присутствует множественный атрибут, то его требуется преобразовать с помощью создания нового объекта.. перепроверка связей типа 1:1. В время создания сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. В подобном случае следует объединить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, необходимо выбрать один из них в качестве первичного, а другой указать как альтернативный ключ. удаление избыточных связей. Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи. Всегда следует стремиться создавать минимальные модели данных, и поэтому, если избыточная связь не является очевидно необходимой, ее следует удалять. Установить, что между двумя сущностями имеется больше одной связи, довольно просто. Однако из этого еще не следует, что одна из двух связей обязательно является избыточной, поскольку обе они могут представлять различные объединения, реально существующие в организации. В нашем примере связь одна, тип связи – «один-ко-многим», сложных, избыточных, рекурсивных и связей с атрибутами нет, множественных атрибутов нет (предполагается, что телефон и банковский счет у фирмы может быть только один), поэтому этот этап пропускается. На данном этапе необходимо на основе созданных локальных логических моделей данных определить наборы отношений, необходимые для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения. Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута (атрибутов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая – дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа. Для каждой присутствующей в логической модели данных бинарной связи типа 1:1, установленной между сущностями Е1 и Е2, необходимо переслать атрибуты первичного ключа сущности Е1 в отношение, представляющее сущность Е2. Для каждой бинарной связи типа 1:М, установленной в логической модели данных между сущностями Е1 и Е2, необходимо переслать копию атрибутов первичного ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, представляющая «единичную» сторону связи определяется как родительская, а сущность, представляющая «множественную» сторону, – как дочерняя. Для представления данной связи необходимо скопировать первичный ключ родительской сущности в отношение, представляющее дочернюю сущность, где этот ключ должен быть описан как внешний. В нашем случае родительской является сущность «Производитель», а дочерней – «Товар», связь между сущностями – «один-ко многим», следовательно, в сущности «Товар» должен быть атрибут, описывающий фирму-производителя. В нашем примере такой атрибут уже предусмотрен, это атрибут «Фирма-производитель», он будет являться внешним ключом. Рассмотрим основы нормализации баз данных. Нормализация используется для улучшения модели данных для того, чтобы модель удовлетворяла различным ограничениям, позволяющим исключить нежелательное дублирование данных. Нормализация гарантирует, что полученная в результате ее применения модель данных будет наилучшим образом отображать особенности использования информации на предприятии, не содержать противоречий, иметь минимальную избыточность и максимальную устойчивость. В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: первая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса–Кодда (BCNF); четвертая нормальная форма (4NF); пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что (N+1)-я нормальная форма не обладает некоторыми непривлекательными особенностями, свойственным N-й нормальной форме. Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. В нашем примере база данных приведена к первой нормальной форме (так как ни одна из строк таблиц не содержит в любом своем поле более одного значения, т.е. все значения атрибутов атомарны), ко второй нормальной форме (так как нет атрибутов, частично зависящих от ключевого поля) и к третьей нормальной форме (так как нет транзитивных зависимостей). После всех преобразований итоговая логическая модель базы данных представлена на рис. 1.3.  Рис. 1.3. Итоговая логическая модель базы данных учета товара в обувном магазине 1.3. Физическое проектирование базы данных (с использованием реляционной СУБД) Физическое проектирование состоит в передаче информационно-логической модели данных в СУБД (в нашем случае, в Visual FoxPro). В таблице имя поля, для Visual FoxPro, может быть до 254 символов, которые входят в базу данных, и 10 символов для таблиц, не включённых в базу данных. Вы можете использовать буквы, цифры и символ подчеркивания в имени поля. Использование знаков пунктуации, специальных символов и пробелов в имени поля не рекомендуется. Кроме того, имя поля не должно начинаться с цифры или знака подчеркивания [2]. Давайте выберем имена для сущностей и атрибутов логической модели данных (табл. 1.2 и табл.1.3). Таблица 1.2 Таблица Товары
Таблица 1.3 Таблица Firms
После определения наименований сущностей и их атрибутов, надо определить тип данных, которым должны быть представлены атрибут (поле таблицы). От домена атрибута зависит какой будет тип данных и это влияет на общий объем данных, скорость поиска, допустимые операции с этим атрибутом и т. д. Так, при выборе типа атрибута, необходимо учитывать следующее: какие значения атрибут может принимать, какие операции будут выполняться с помощью этого атрибута, сколько физического места будет занимать одно значение атрибута. Возможные типы данных для полей таблиц, которые поддерживает Visual FoxPro представлены в таблице. 1.4 [2, 3]. Таблица 1.4 Типы данных
Для рассматриваемого примера данные будут иметь следующий тип и размер (табл. 1.5 и табл. 1.6): Таблица 1.5 Типы данных для таблицы Товар
Таблица 1.6 Типы данных для таблицы Фирма
|