Много информации это просто груда мусора


Лекция 7. Этапы проектирования БД



страница5/9
Дата29.04.2018
Размер1.56 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9

Лекция 7. Этапы проектирования БД

  1. Этапы проектирования БД


Следующие пункты представляют основные этапы проектирования БД:


  1. Системный анализ. Определить информационные потребности БД.

  2. Сформировать из объектов предметной области сущности и характеристики этих сущностей в виде списка (например, для сущности "деталь" характеристиками могут быть "название", "цвет", "вес" и т.п.).

  3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля), учитывая соглашения выбранной Вами СУБД.

  4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

  5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.

  6. Установить связи между объектами (таблицами, полями).

  7. Провести нормализацию таблиц.

  8. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

Рассмотрим детально перечисленные этапы проектирования БД:






  1. Ключевым этапом при разработке любой информационной системы является проведение системного анализа:

  1. формализация предметной области;

  2. представление системы как совокупности компонент.

Системный анализ позволяет, с одной стороны, лучше понять «что надо делать» и «кому надо делать» (аналитику, разработчику, руководителю, пользователю), а с другой – отслеживать во времени изменения рассматриваемой модели и обновлять проект.


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

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




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




  1. объектный (предметный) подход сосредотачивает основное внимание на выделении существенных объектовпредметов и связей, информация о которых может быть использована в прикладных задачах пользователя.

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


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


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




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




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




  1. БД должна быть рассчитана на возможность расширения при реорганизации и расширении предметной области.




  1. БД должна легко изменяться при изменении программной и аппаратной среды.




  1. Загруженные в БД корректные данные должны оставаться корректными.




  1. Данные до включения в БД должны проверяться на достоверность.




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

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




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




Моделирование концептуального уровня БД включает в себя:


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




  • идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс "ведение учета работающих" идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.




  • идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.




  • идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.




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


Получение реляционной схемы из ER-диаграммы


  1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.




  1. Каждый атрибут становится столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.




  1. На четвертом шаге определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Необходимо определить первичный ключ для каждого из отношений. На языке модели "сущность – связь" ключ это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

Если нет возможности идентифицировать экземпляр сущности с помощью одного атрибута, то первичный ключ нужно сделать составным (composite primary key) - из нескольких атрибутов. Хорошим примером может быть первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Если и несколько атрибутов не идентифицируют экземпляр сущности однозначно, то можно ввести искусственный первичный ключ с типом данных счетчик. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Все возможные атрибуты сущности, уникальным образом ее идентифицирующие, называются потенциальными ключами.


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

  • суммарной длины атрибутов;

  • минимального количества атрибутов в ключе;

  • наличия гарантий уникальности его значений в текущий момент времени и в обозримом будущем.

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


Во многих СУБД имеется возможность помимо первичного определять еще ряд уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача - гарантировать уникальность значения поля.
Для первичного ключа, а также внешних ключей и тех атрибутов, которые часто используются в запросах, создаются индексы. Если содержащий необходимые данные файл просматривается последовательно, т. е. с начала и переходя к последующим записям по очереди, то может быть потрачено много времени, особенно если это – большой файл. Если файл имеет индекс (предметный указатель), то поиск значительно ускоряется.
Индекс в БД работает также, как и алфавитный указатель в книге. Если искать материал по какой-то теме, то одним способом является перелистывание книги до тех пор, пока не отыщется необходимый материал. Но более быстрый способ – это посмотреть в алфавитный указатель (индекс), в котором указана страница, на которой идет речь по необходимой теме.
В БД можно указать, какое поле считать индексированным, и создать индексный файл (INDEX FILE), в котором будет храниться содержание указанного поля и порядковый номер каждой записи.
При помощи индексного файла можно значительно ускорить поиск необходимых данных: просматривается индексный файл на предмет необходимых данных, получаемый в результате порядковый номер дает доступ ко всей записи.
Можно создать несколько индексный файлов для одной таблицы БД, используя различные поля в качестве индексированных.


  1. Пятый шаг предполагает выработку правил, которые будут устанавливать и поддерживать целостность данных (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность).

Под ссылочной целостностью данных (referential integrity) подразумевается логическая непротиворечивость данных и правильность данных в любой момент времени.


Правила целостности данных включают:


  • определение типа данных;

  • создание полей, опирающихся на экземпляры сущности;

  • установка значений по умолчанию;

  • определение ограничений целостности;

  • определение проверочных условий.


Целостность данных может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в БД (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить проверочное условие: номера дней недели должны принадлежать набору
(1, 2, 3, 4, 5, 6, 7).
Целостность данных обеспечивается набором специальных предложений, называемых ограничениями целостности. Ограничения целостности представляют собой утверждения о допустимых значениях отдельных информационных единиц и связях между ними. Ограничения целостности определяются в большинстве случаев особенностями предметной области, хотя могут отражать и чисто информационные характеристики.
Ограничения целостности могут относиться к разным информационным объектам: атрибутам (полям), кортежам (строкам, записям), отношениям (таблицам, файлам), связям между файлами и т.п.
Выделяют две группы ограничений целостности:

  1. В процессе проектирования:

    1. при получении достоверных данных из источников;

    2. при построении структуры;

    3. при заполнении БД данными.

  2. При эксплуатации:

    1. машинные сбои;

    2. ошибки оператора.

В первой группе выделяют три типа правил целостности:



  1. Целостность по сущностям.

Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.




  1. Целостность по ссылкам.

Значение внешнего ключа должно либо:




    1. быть равным значению первичного ключа;

    2. быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.




  1. Корпоративная целостность или целостность, определяемая пользователем.

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




  1. уникальность тех или иных атрибутов,

  2. диапазон значений (экзаменационная оценка от 2 до 5),

  3. принадлежность набору значений (пол "М" или "Ж").

Ссылочная целостность уменьшает быстродействие из-за проверки условий – связей через словарь.




  1. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами).


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


Использование связей позволяет:


  1. уменьшить объем хранимых данных;

  2. обеспечить полноту и корректность данных на уровне их структуры за счет соблюдения следующего правила: данные об одном объекте вводятся в БД только один раз.




Каталог: upload -> iblock -> 549
iblock -> Часы-смартфон
iblock -> Руководство пользователя для телефона Apple iPhone 6
iblock -> Руководство по эксплуатации Методика калибровки Технические характеристики. Минимальный радиус кривизны поверхностей контролируемых изделий, 6мм
iblock -> Технические требования
iblock -> Технологические карты
iblock -> Оптимизация процесса восстановления измененных и уничтоженных маркировочных обозначений на блоках двигателей транспортных средств
iblock -> Инструкция по эксплуатации Температурный gsm извещатель Grinson T7 Благодарим Вас за выбор температурного gsm извещателя Grinson T7
549 -> Гост 4011-72 Вода питьевая. Методы измерения массовой концентрации общего железа


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница