WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 |
Санкт-Петербургский государственный университет Факультет филологии и искусств Кафедра информационных систем в искусстве и гуманитарных науках П.П. Щербаков Создание баз данных в среде MYSQL Учебное пособие Санкт-Петербург 2007 0 1 Рекомендовано к изданию Кафедрой информационных систем в искусстве и гуманитарных науках Факультета филологии Введение и искусств Санкт-Петербургского государственного университета В настоящее время растет потребность в создании информационных систем, основанных на базе данных, для различных предметных областей.

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

сервера базы данных (СУБД) используется широко распространенный в Создание баз данных в среде MYSQL: Учебное пособие. — СПб.:

настоящее время сервер MYSQL, являющийся, практически, стандартом для Ф-т филологии и искусств СПбГУ, 2007. — 35 с.

создания ВЕБ-ориентированных систем.

Учебное пособие посвящено решению задач создания базы данных в среде MySQL Целью настоящего пособия является показать на примере Раздел 1. Постановка задачи и ограничение конкретной задачи студентам кафедры информационных систем в искусстве предметной области и гуманитарных науках процесс разработки базы данных 1.1. Введение: Описание решаемых задач Работа над созданием базы начинается с описания предметной области, для которой предназначена создаваемая информационная система, Подготовка и издание учебного пособия осуществлено в определения информационных потребностей, которые эта система должна рамках проекта СПбГУ «Инновационная образовательная удовлетворять, и создания концептуальной схемы базы данных. Эта работа среда в классическом университете» предшествует непосредственной разработке кода, обеспечивающего (Приоритетный национальный проект «Образование»).

функциональность базы данных.

Описание предметной области очерчивает круг сведений, которые будут храниться в разрабатываемой базе данных. Слишком широкий набор сведений, предназначенный для хранения базы данных повлечет неоправданное усложнение системы и увеличение объема хранимой © П.П. Щербаков, информации, что, безусловно, скажется на сложности и трудоемкости © Факультет филологии и искусств Санкт-Петербургского государственного разработки системы, трудовых затратах на наполнение и сопровождение базы университета, данных и общей эффективности информационной системы. При описании предметной области объекты реального мира подвергаются классификации, фиксируется совокупность подлежащих отображению в базе данных типов объектов. Для каждого типа объектов фиксируется совокупность свойств, посредством которых будут описываться конкретные объекты этого типа в Отпечатано с готового оригинал-макета в секторе цифровой печати базе данных, виды отношений (взаимосвязей) между этими объектами. Затем Института искусств Факультета филологии и искусств СПбГУ решаются вопросы о том, какая информация об этих объектах должна быть 199178 Санкт-Петербург, 10 линия В.О., д. 49.

представлена в базе данных и как ее представить с помощью данных. При Подписано в печать 10.11.2007. Заказ № 55. Формат 60х84/16. Усл. печ. л. 2,2. Тираж 50 экз.

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

Описание информационных потребностей, которые должна обслуживать 1.2. Описание информационных запросов разрабатываемая информационная система, позволяет определить объекты хранения, уточнить структуру данных, содержательное наполнение базы. Как Обратимся теперь к информационным потребностям. Что же мы хотим от правило, хорошо описанные информационные потребности позволяют нашей системы Попробуем сформулировать возможный набор создать эффективные средства обслуживания запросов пользователя.

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

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

• С каким адресом связан данный номер телефона Рассмотрим эти этапы проектирования более подробно на примере • Какие еще телефоны есть у владельца данного номера создания «Электронного телефонного справочника» • Какие телефонные номера связаны с конкретным адресом • Какие телефонные номера не связаны с адресом или владельцем (это для администратора) 1.2. Описание предметной области • Какие номера телефонов или владельцы телефонов ассоциируются с конкретной сферой деятельности Зададимся вопросом, для кого предназначена разрабатываемая Сформулированные запросы дают нам представление о том, как должна быть информационная система – для частного лица, для компании, организована информация.

специализирующейся на рекламе, для телефонной компании, для налоговой инспекции…. Список тех, кому может понадобиться такая система можно 1.3. Описание объектов хранения продолжить, однако для нас имеет смысл определиться. Будем разрабатывать телефонный справочник для частного лица – некоторый аналог записной книжки. Название организации и имя владельца должны храниться в базе и по ним должен осуществляться поиск. С организацией может быть связано несколько Какая информация должна храниться в базе Вот первый пришедший в телефонов, владельцев, адресов и т.д. То же относится и к владельцам голову список.



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

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

Владелец Адрес Организация Телефонный Уточним содержание хранимой информации.

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

Какие свойства объектов, или другими словами, атрибуты должны храниться Как могут или должны представляться и обрабатываться Адрес – страна, город, улица, дом, квартира или офис, всякие дроби, корпуса, литеры, строения, подъезды, звонки, ближайшая станция метро и тд.

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

Дата рождения Это обстоятельство может служить основанием для ограничения предметной Характеристику области.

Фотографию Название улицы, кажется, удовлетворяет тем же условиям что и Имя в описании владельца, однако анализ того, сколькими способами может быть В данном случае мы не создаем реальную базу данных, которая будет записано название, например, «набережная реки Карповки» говорит о том, распространяться, главной целью является иллюстрация того, как происходит что название улицы необходимо сверять с некоторым внутренним процесс создания. С этой точки зрения проанализируем перечисленные справочником или списком. Скорее всего, целесообразно такой список свойства с точки зрения типов данных, которые будут использоваться выделить в отдельный объект хранения. В противном случае не совсем ясно, непосредственно в базе данных.

как система узнает, что «реки Карповки набережная» и «наб. Карповки» Имя и Фамилия могут храниться как текстовые строки, которые являются одним и тем же.

представляют из себя последовательности символов ограниченной длины.

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

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

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

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

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

данных связанных с временем и датой.

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





необходимо следить, чтобы в ней не встречались буквы, число цифр Фотография – в базе данных может храниться не только текстовая соответствовало.

информация.

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

Страну Город Организация Район 6 Можно ограничится только названием, однако к нему относится все то, что сказано о хранении названий улиц Телефон- Владелец Адрес С точностью до выяснения того, как организовать список улиц, наши ный номер телефона объекты хранения можно изобразить следующим образом Организаци Адрес Владелец Телефонный я телефона номер Улицу Название Номер дома Фамилия Номер Квартира Имя Имя Доп. инф Дата рождения провайдера Характеристика Провайдер Органи- Улица зация 1.4. Описание идентифицирующих атрибутов (ключей) Объекты необходимо различать. Это можно сделать, анализируя содержимое всех свойств объектов хранения, а можно ограничиться только Такое изображение говорит нам только о том, какие объекты связаны.

несколькими свойствами, относительно которых придется сделать замечание Для нас же важно где нужно хранить информацию о связях. Покажем об уникальности. Самым простым способом является введение независимого стрелочками, куда должны указывать связи атрибута, который ни у одного из хранимых объектов одного типа не повторяются. Такой подход позволит, например, правильно идентифицировать улицу, даже если ее название изменилось 1.5. Описание связей между объектами Телефон- Владелец Адрес ный телефона Кроме хранения информации об объектах необходимо учитывать, в каких номер отношениях они находятся.

В реляционных базах данных, представителем которых является MYSQL, связи между объектами реализуются через значения некоторых атрибутов объектов хранения:

Например, в объекте Адрес может храниться значение ключевого атрибута описывающего улицу. Важным является понимание того, где ПровайОргани- Улица должна храниться связующая информация. Попробуем разобраться, как дер организовать связи между нашими объектами. зация Сначала попытаемся визуализировать наши связи 8 Добавленные стрелочки указывают, какой из объектов должен указывать на связанный с ним. Разберемся, как выбирать объекты, которые будут Связь Адрес Телефон- Владелец хранить информацию о связях между объектами. У Телефонного номера один Адрес - ный номер телефона Владелец, но у Владельца может быть несколько Телефонных номеров. Это Владелец значит, что если информацию о ссылке хранить объектеТелефонный номер, то для него достаточно отвести одно дополнительное поле, содержащее значение ключевого поля объекта Владелец телефона. Если ссылки натобъекты Телефонный номер хранить в объекте Владелец телефона, то либо на каждую ссылку нужно заводить отдельный атрибут, либо хранить в Организация Провайдер одном поле несколько ссылок (например список, разделенный запятой), и Улица предусмотреть механизм выделения нужной ссылки, что представляется нецелесообразным. Такой тип связи получил название "один-ко-многом".

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

не соответствовать требованиям задачи.

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

несколькими Адресами, что делает нецелесообразным хранение информации Сведем полученную нами информацию в таблички о связях и в объекте Владелец телефона. Такие связи получили название "многие-ко-многим". Решение задачи хранения информации о связях такого Имя объекта: provider типа обычно связано с созданием дополнительного промежуточного объекта Имя атрибута Тип данных атрибута Дополнительные условия хранения, в котором хранится информация об обоих связанных объектах и id_provider Целое число Первичный ключ связь "многие-ко-многим" таким образом заменяется парой связей "один-коprovider_na Строка переменной многим" me длины Прежде чем изображать получившуюся блок-схему отметим различие между имеющимися связями. Телефон обязательно имеет Владельца, в Имя объекта: phone Адресе обязательно должна быть указана Улица, а вот Владелец телефона Имя атрибута Тип данных атрибута Дополнительные условия может быть не связан ни с одной организацией. И та и другая ситуация id_phone Целое число Первичный ключ требует внимательного отношения при реализации проекта.

phone_numb Строка фиксированной Изобразим получившуюся блок-схему.

Pages:     || 2 | 3 | 4 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.