[МУЗЫКА] [МУЗЫКА] В основе любой информационной системы лежит база данных. Давайте разберем, из каких этапов строится создание базы данных или ее разработка. Вначале мы должны определиться с предметной областью, информацию о которой мы будем хранить, и специфицировать все требования, которые мы к ней предъявляем. Это могут быть объекты реального мира, их связи, отношения друг с другом. Также мы должны предусмотреть возможные размеры, которых достигнет база данных, какое количество пользователей будет с ней обращаться. В зависимости от этих требований подбирается некая реальная СУБД, в контексте которой будут описаны основные структуры и объекты, необходимые для представления данных. Также СУБД должна позволять нам возможность описывать правила целостности и некую бизнес-логику. Когда СУБД выбрана, структура базы данных описана, можно переходить непосредственно к процессу реализации базы данных. На этом этапе будут созданы объекты базы данных и они заполняются непосредственными данными. Потом потребуется труд тестировщиков, которые проверят, что все данные описаны корректно, правила бизнес-логики реализованы. Также должна быть разработана документация, которая позволит пользователям общаться с базой данных, а администраторам ее поддерживать. Сегодня мы поговорим с вами о первом этапе, одном из важнейших этапов — о том, каким образом определяются требования к базе данных. Назовем это процессом моделирования. Процесс моделирования начинается с изучения понятий и описаний. Мы должны понять, какие данные мы хотим хранить, и самое важное, на какие вопросы пользователей к этим данным мы должны находить ответы в базе данных. При моделировании мы должны описать объекты и понятия выбранной предметной области и проследить связи между ними. Также должны быть описаны ограничения целостности, то есть требования к допустимым значениям данных и связи между ними. Рассмотрим предметную область. Например, нам нужно создать информационную систему, которая будет называться «Экзаменационная сессия». Какую информацию мы будем хранить? Мы должны хранить информацию о том, как студенты распределены по группам. Должны хранить информацию о студентах. Наверное, информация о студенте будет содержать номер его зачетки, фамилию, имя, отчество, и мы догадываемся, что в номере зачетки не бывает букв, в фамилии не бывает цифр, студент должен состоять только в одной группе. Дальше, когда мы назначаем экзамен, экзамен должен быть по конкретному предмету, его должен принимать определенный преподаватель. Результатом экзамена является экзаменационная оценка, которая бывает в допустимом диапазоне. Таким образом, мы привели пример описания предметной области и неких ограничений целостности и правил бизнес-логики. Какое замечание хочется сделать: чтобы подчеркнуть важность стадии моделирования, можно привести так называемый 16-й закон систематики, который называют законом Мерфи, о том, что сложная система, спроектированная наспех, никогда не работает, и исправить ее, чтобы заставить работать, невозможно. Это говорит о том, что стадия проектирования данных чрезвычайно важна. На этапе моделирования данных мы должны составить семантическую модель. Это модель очень высокого уровня, то есть мы должны абстрагироваться при составлении семантической модели от конкретной СУБД, в рамках которой будет реализована база данных, а тем более от особенностей физического хранения. С чего начать процесс моделирования данных? Нужно начать с анализа предметной области и с выявления требований к ней отдельных пользователей. Если мы рассматриваем базу данных «Экзаменационная сессия», то, наверное, у разных пользователей будут разные задачи, связанные с этой базой данных. Студентам нужно узнать, когда и в какую аудиторию они должны прийти на экзамен, преподаватель должен иметь возможность проставить оценку за экзамен, а администратор учебного заведения должен составлять расписание экзаменационной сессии и назначать предметы и преподавателя для проведения экзамена. Представления отдельных пользователей обобщаются в концептуальную схему базы данных. Она может быть описана на естественном языке при помощи математических формул, таблиц, графиков и других средств, которые позволяют людям, которые будут разрабатывать проект базы данных, понять структуру предметной области. Эту модель еще называют инфологической моделью данных. После разработки инфологической модели можно приступать к даталогическому моделированию. На этом уровне мы описываем структуры хранения в контексте выбранной СУБД. А с физическим уровнем хранения данных имеют дело уже инструменты, выбранные СУБД. Схемы, на которых выделены уровни представления данных, вы видите на этом слайде. Трехуровневая архитектура позволяет нам обеспечить независимость хранимых данных от использующих их программ. Администратор базы данных при необходимости может переписать данные на другое устройство, или разбить их на части, если база данных достигла очень больших размеров. Он может подключать к ней различных пользователей. Но указанные изменения физической модели данных никоим образом не скажутся на логической структуре данных. Также, если нам потребуется каким-то образом видоизменить логическую структуру данных, то это не потребует изменений физических устройств хранения. Каким образом можно описывать семантическую модель? Для семантического моделирования наиболее известной моделью является модель «сущность — связь», разработанная Питером Ченом в 1976 году. Эта модель обычно представляется в графической форме с использованием оригинальной нотации Чена, которая называется диаграммой «сущность — связь» или entity-relationship diagram. Основными преимуществами этой диаграммы являются наглядность, возможность представлять произвольное количество данных с любым количеством свойств. И на этой модели основано множество систем автоматизированного проектирования баз данных, например ERV. В дальнейшем, многими авторами были разработаны подобные модели, но главное их достоинство состоит в наглядности, потому что рисунок всегда понятнее текстового описания. Диаграмму «сущность — связь» можно считать инструментом концептуального уровня, и важная его особенность заключается в том, что он не содержит операций и поэтому не может быть использован непосредственно. Но диаграммы «сущность — связь» являются развитой системой зависимости и ограничений целостности. Зачем нам нужны диаграммы «сущность — связь»? Они являются способом проектирования данных, позволяют нам идентифицировать понятия предметной области и связи между ними, и дают нам легкий удобный графический интерфейс, который описывает структуру базы данных. Что будет основными элементами диаграммы «сущность — связь»? Это будут сущности, атрибуты и связи. Что мы понимаем под сущностью? Это любой объект или понятие, информацию о которых мы собираемся хранить. Свойства сущности называются атрибутами, и сущности вступают в некие отношения друг с другом, которые мы называем связями. На этом слайде вы видите примеры основных понятий, которые могут быть использованы в диаграмме «сущность – связь». Это будет набор независимых сущностей, которые будет окружены в прямоугольнике. Двойными прямоугольниками мы будем окружать зависимые сущности, атрибуты мы изображаем в овалах. Особенно важные атрибуты, которые мы назовем ключами, окружаем овалами и подчеркнем прямой линией. Наборы связи мы заключаем в ромбы, и линии будут связывать сущности с описывающими их атрибутами, а направленные линии будут указывать на связи между объектами. Рассмотрим пример, описанной нами экзаменационной сессии. В нашей базе данных должна храниться информация о студентах, сданных ими экзаменах по определенным предметам. Студент характеризуется номером зачетки, фамилией, именем, отчеством, датой рождения. Студент может иметь несколько телефонов, все студенты распределены по учебным группам, для группы назначается экзамен по определенному предмету, назначается экзаменатор, указывается дата экзамена и аудитория, за каждый сданный экзамен студенту ставится оценка. Какие мы можем выделить сущности? Сущностью является любой объект или понятие, информацию о которых мы храним. Мы видим, что сущностями у нас будут студенты, будут преподаватели, будут сданные предметы. Какими свойствами будут обладать эти сущности или какие у них будут атрибуты? Это будет фамилия, имя, отчество, дата рождения, номер зачетки. И мы сразу можем представить, какие ограничения могут быть наложены на наши данные: номер зачетки — положительное число, фамилия, имя отчество — не бывает цифр, оценка бывает от двух до пяти, студент состоит в одной учебной группе, в один день можно сдать один экзамен. Для чего нам потребуются диаграммы? Любой проектировщик или аналитик базы данных при помощи составления этой диаграммы может получить лучшее понимание предметной области. Также диаграммы могут служить инструментом для документации. Диаграммы «сущность — связь» передают нам логическую структуру базы данных и помогут использовать ее конечным пользователям. О том, как описываются сущности и связи между ними мы поговорим далее.
