Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Этапы проектирования базы данных




Все тонкости построения информационной модели преследуют одну-единственную цель - получить хорошую базу данных. А что это такое?

Существует очень простое понятие базы данных как большого по объему хранилища, в которое организация помещает все используемые ею данные и из которого различные пользователи могут их получать, используя различные приложения. Такая единая база данных представляется идеальным вариантом, хотя на практике это решение по различным причинам труднодостижимо. Поэтому чаще всего под базой данных понимают любой набор хранящихся в компьютере взаимосвязанных данных.

В основу проектирования БД должны быть положены представления конечных пользователей конкретной организации - концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к базе данных информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Данные, помещаемые в базу данных, также предоставляет конечный пользователь.

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

• База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.

• База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.

• База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

• База данных должна легко расширяться при реорганизации и расширении предметной области.

• База данных должна легко изменяться при изменении программной и аппаратной среды,

• Загруженные в базу данных корректные данные должны оставаться корректными.

• Данные до включения в базу данных должны проверяться на достоверность.

• Доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.

Этапы проектирования базы данных представлены на рис 5.5.1

В результате анализа поставленной заказчиком задачи и обработки требований конечных пользователей составляется концептуальная модель. При разработке логической модели базы данных, прежде всего, необходимо решить, какая модель данных наиболее подходит для отображения конкретной концептуальной модели предметной области. Коммерческие системы управления базами данных поддерживают одну из известных моделей данных или некоторую их комбинацию. Почти что все популярные системы для персональных компьютеров поддерживают реляционную модель данных. Отображение концептуальной модели данных на реляционную модель производится относительно просто. Каждый прямоугольник концептуальной модели отображается в одно отношение, которое отражает представление пользователя в удобном для него табличном формате. Простота отображения связана с тем, что при разработке концептуальной модели использовался реляционный подход. Рассмотрим этапы проектирования базы данных, которые должны обеспечить необходимую независимость данных и выполнение эксплуатационных требований и пожеланий пользователей. (При описании этапов проектирования базы данных мы будем ссылаться на базу данных «Путевые листы»).

Этап 1. Определение сущностей (см. рисунок 5.4.1)

Этап 2. Определение взаимосвязей между сущностями. Информационная модель также представлена на рис.5.4.1. Связь между таблицей «Путевые листы» и «Список водителей», а также «Путевые листы» и «Справочник автомобилей» определена как «много-к-одному». Остальные связи - «Один-к-одному».

Этап 3. Определение атрибутов сущностей и первичных ключей. Атрибуты таблиц представлены в таблицах 5.4.1-5.4.8. при переходе от логической модели к физической модели данных может произойти усечение числа объектов. С изменением алгоритма расчетов может произойти корректировка объектов. Процесс выбора показателей, которые обязательно следует хранить в базе данных, достаточно сложен. Нечасто можно найти однозначное решение этой проблемы. В любом случае оно потребует тщательного изучения работы предприятия и анализа концептуальной модели.

 
 


Рис 5.5.1 Схема проектирования базы данных

 

После определения состава атрибутов, необходимо определить первичные ключи. Обычно (следуя определению первичного ключа) они определяются для таблиц, содержащих нормативно-справочные данные. Окончательно взаимосвязи таблиц с учетом определения первичных ключей можно представить в следующем виде (рис 5.5.2):

 
 

 

 


Рис.5.5.2 Взаимосвязи между атрибутами сущностей (таблиц)

Этап 4. Приведение модели к требуемому уровню нормальной формы. Для выполнения этого этапа нужно следовать следующим правилам:

- Исключить повторяющиеся группы. Для каждого набора атрибутов создать отдельную таблицу и снабдить ее первичным ключом.

- Исключить избыточные данные. Если атрибут зависит только от части составного ключа, его следует переместить в отдельную таблицу. Это правило помогает избежать потери одних данных при удалении каких-то других. Везде, где возможно использование идентификаторов вместо описания, надо вынесьти в отдельную таблицу список идентификаторов с пояснениями к ним.

- Исключить столбцы, которые не зависят от ключа - если атрибуты не вносят свою лепту в описание ключа, их надо переместить в отдельную таблицу.

Вышеизложенным правилам отвечает схема, представленная на

рис. 5.5.2. В процессе нормализации появляется необходимость введения искусственных реквизитов. В общем случае рекомендуется вместо естественных атрибутов использовать коды. Это будет способствовать повышению быстродействия проектируемой системы.

- В предметной области может наблюдаться повторения, то есть естественный атрибут отношения не обладает свойством уникальности. Например, среди сотрудников фирмы могут быть однофамильцы или даже полные тезки. В этом случае решить проблему помогает уникальный табельный номер.

- Если отношение участвует во многих связях, то для их отображения создается несколько таблиц, в каждой из которых повторяется идентификатор отношения. Для того чтобы не использовать во всех таблицах длинный естественный атрибут объекта, можно применять более короткий код. Это также будет способствовать повышению производительности системы.

- Если естественный атрибут может изменяться во времени (например, фамилия), то это может вызвать очень большие сложности при эксплуатации системы. Что будет с данными, которые привязаны к фамилии? Использование неизменяемого кода (табельного номера) позволит избежать этих сложностей.

Атрибуты, включаемые в модель, приведены в таблице 5.5.1.

Сущность Первичный ключ Атрибуты
Путевые листы Поле связи ТабНомер
  Поле связи ГосНомер
    № путевого листа
    Дата выезда
    Показания спидометра при выезде
    Показания спидометра при возвращении
    Пробег по городу
    Пробег по трассе
    Пробег по крупному городу
    Остаток бензина при выезде
    Заправка
Паспортные данные Уникальный ключ ТабНомер
    Фамилия
    Имя
    Отчество
    Адрес
    Телефон
Организации Уникальный ключ КодОрг
    Наименование
Группы персонала Уникальный ключ КодГруппы
    Наименование
Справочник автомо- Уникальный ключ ГосНомер
билей   Марка
    Дата учета
    Норма расхода бензина по городу
    Норма расхода бензина по трассе Норма расхода бензина по крупному городу
     

Таблица 5.5.1 Атрибуты и первичные ключи сущностей информационной модели.

Этап 5. На этом этапе надо составить проекты таблиц, которые будут реализованы в конкретной СУБД. Мы рассмотрим подробно проектирование таблиц в следующей главе. А сейчас остановимся подробно на обеспечении целостности. Это обеспечит безопасность и точность информации, хранящейся в базе данных.

f Обеспечением целостности называется система мер, направленная на поддержание правильности данных в базе данных в любой момент времени.

Затраты на проверку и поддержание достоверности данных могут составлять значительную часть от общих эксплуатационных затрат. Например, в автотранспортных предприятиях для контроля правильности ввода путевой документации практикуется параллельный ввод одних и тех же данных несколькими операторами. Считается, что вероятность совершения одной и той же ошибки в этом случае мала. Конечно, появляется соблазн избежать дорогостоящего контроля данных. Ошибки же в данных неприятны тем, что они остаются незамеченными до тех пор, пока не проявятся неприятные последствия. СУБД предоставляет меры для блокирования возможных ошибок в создаваемой базе данных. В СУБД целостность данных обеспечивается набором специальных предложений, называемых целостностью данных. Ограничения целостности в большинстве случаев определяются особенность предметной области. Например, при вводе данных из путевого листа, вряд ли возможен пробег по городу за день, равный 1000 км. Ограничения целостности могут относиться к разным объектам: полям (атрибутам), записям, отношениям, связям между ними и т.д. Для полей могут использоваться следующие ограничения:

- Тип и формат поля автоматически допускают ввод данных только определенного типа.

- Задание диапазона значений для числовых полей.

- Недопустимость пустого поля позволяет избежать появления в БД записей, в которых пропущены какие-либо обязательные атрибуты.

- Задание списка значений позволяет избежать излишнего разнообразия данных. Например, для указания марки автомобиля мы можем ограничить пользователя только общепринятыми обозначениями.

- Проверка на уникальность значения какого-либо поля позволяет избежать записей-дубликатов. Например, в справочнике водителей вряд ли надо держать несколько записей об одном и том же водителе.

Для реализации ограничений целостности, имеющих отношение к записям, таблицам или взаимосвязей между ними, в СУБД используются триггеры.

f Триггеры - это предварительно определенное действие или последовательность действий, автоматически осуществляемых при выполнении операций обновления, добавления или удаления записей.

Триггер включает в себя следующие компоненты:

- Ограничения, для реализации которых и создается триггер.

- Событие, которое будет характеризовать возникновение ситуации, требующей проверки ограничений. Это обычно события, связанные с изменением состояния БД (добавление, удаление записи).

- Предусмотренное действие для реализации логика ограничений.

Конкретно реализацию ограничений целостности Вы рассмотрите при изучении главы по созданию БД средствами ACCESS (заметим в скобках, что каждая СУБД имеет свою реализацию ограничений целостности).

 

 




Поделиться с друзьями:


Дата добавления: 2014-01-15; Просмотров: 586; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.026 сек.