Базы данных и My Visual Database. Давайте представим, что вы ведете учет чеголибо в обычной Excel таблице, как показано на рисунке 1
 Скачать 3.69 Mb.
|
|
frmClient: Создайте новую форму, нажав кнопку . Введите название формы frmClient Расположите компоненты на данной форме как показано на рисунке 41. Рис.41 Именно данная форма является главным отличием от нашего предыдущего проекта. Теперь записи об аренде техники расположены не на главной форме, а на форме frmClient, и на этой форме вы видите не только данные клиента, такие как его имя и телефон, но и все записи связанные с арендой техники данным клиентом. Форма frmRent: Создайте новую форму, нажав кнопку . Введите название формы frmRent Расположите компоненты на данной форме как показано на рисунке 42. Рис.42 Данная форма предназначена для создания записи об аренде. Обратите внимание, в отличие от нашего предыдущего проекта, на данной форме нет выпадающего списка, в котором бы мы выбрали клиента, который арендует указанную технику. Дело в том, что форма frmRent будет вызываться из формы frmClient, поэтому программа автоматически свяжет клиента с данной формой, и запись об арендованной технике автоматически будет принадлежать клиенту, данные которого будут на форме frmClient. Другими словами, вам просто не нужно беспокоиться об этом, программа автоматически свяжет клиента и арендованную им технику. Форма frmTechList: Создайте новую форму, нажав кнопку . Введите название формы frmTechList Расположите компоненты на данной форме как показано на рисунке 43. Рис.43 Данная форма точно такая же, как и в предыдущем проекте. На создаваемой форме сможем видеть всю технику, которой располагаем, а так же вызвать форму для добавления новой техники, если вдруг такая появилась, либо редактировать информацию о существующей. Форма frmTech: Создайте новую форму, нажав кнопку . Введите название формы frmTech Расположите компоненты на данной форме как показано на рисунке 44. Рис.44 Данная форма точно такая же, как и в предыдущем проекте. Предназначена для создания/редактирования техники, которой вы располагаете, с указанием ее стоимости аренды в день. Переходим к последнему этапу создания приложения, к настройке компонентов на форме. Как вы помните, настройка компонентов сводится к тому, чтобы кнопкам присвоить действие, а компонентам предназначенные для ввода информации (такие как: и т.д.) указать, к какой таблице БД, и к какому полю они принадлежат. Приступаем к настройке форм, я лишь перечислю, какие действия необходимо присвоить кнопкам и какие поля БД присвоить компонентам на форме. Подробней остановлюсь на компонентах, чья настройка отличается от предыдущего проекта. Настройка формы Form1: Имя клиента (текстовое поле) TableName = Client FieldName = Name Телефон (текстовое поле) TableName = Client FieldName = Phone Новый клиент (кнопка) Действие = Новая запись Форма = frmClient Редактировать (кнопка) Действие = Показать запись Компонент таблицы = TableGrid1 Форма = frmClient Удалить (кнопка) Действие = Удалить запись Компонент таблицы = TableGrid1 Чуть подробней остановимся на настройке кнопки Найти. Как я упомянул ранее, на главной форме теперь мы будем видеть записи о клиентах, а не записи об аренде, как в предыдущем проекте. Поэтому данная кнопка будет искать данные в таблице Client, вместо таблицы Rent. На рисунке 45 можете видеть настройки кнопки Найти. Рис.45 Настройка формы frmClient: Имя клиента (текстовое поле) TableName = Client FieldName = Name Телефон (текстовое поле) TableName = Client FieldName = Phone Новая аренда (кнопка) Действие = Новая запись Форма = frmRent Редактировать (кнопка) Действие = Показать запись Компонент таблицы = TableGrid1 Форма = frmRent Удалить (кнопка) Действие = Удалить запись Компонент таблицы = TableGrid1 Чуть подробней остановимся на настройке кнопки Сохранить. Настройку данной кнопки можете видеть на рисунке 46. Рис.46 Обратите внимание, компонент TableGrid1 не участвует в сохранении в записи, а просто показывает записи об аренде принадлежащие клиенту на форме. Поэтому оставьте его в левом списке. Также подробней остановимся на настройке (рис.47) компонента TableGrid1 (Арендованная техника клиентом). В данном компоненте мы будем видеть записи об аренде техники, которые принадлежат клиенту, чьи данные мы видим на текущей форме (frmClient). Рис.47 Обратите внимание на выбранную настройку «Показать дочерние записи (если имеются)». Таким образом, в данном компоненте автоматически будут показаны дочерние записи, в нашем случае по отношению к клиенту, другими словами мы будем видеть записи об аренде, которые принадлежат клиенту. Если кто-то забыл, что такое дочерние записи, можете взглянуть на рисунок 48. Рис.48 Т.е. если на форме frmClient мы видим данные о клиенте KH Services, то в компоненте TableGrid1 мы увидим дочерние записи из таблицы Rent, которые на рисунке отмечены красным. Настройка остальных форм, такие как frmRent, frmTechList, frmTech ничем не отличается от нашего предыдущего проекта, настройте их самостоятельно. После того, как вы закончили с настройками оставшихся форм, время запустить наш проект, нажав кнопку и протестировать его работу. Как и в прошлом проекте, сначала необходимо добавить в базу данных технику, которой мы располагаем и ее стоимость за 1 день аренды, для этого на главной форме нажмите кнопку «Техника» (рис.49). Рис.49 После того, как вы добавил в базу данных всю технику, который располагаете, можно приступить непосредственно к работе. Допустим, к нам обратилась фирма «KH Services», чтобы арендовать Бульдозер ТМ-10, Автокран К-4561 и тягач Kenworth W900. И если эта фирма обратилась к нам первый раз, тогда на главной форме нажимаем кнопку «Новый клиент». Появится форма frmClient на которой мы введем данные клиента и на этой же форме нажмем кнопку «Новая аренда», чтобы поочередно присвоить данному клиенту арендованную им технику (рис.50). Рис.50 Обратите внимание, если клиент уже существует в базе данных, вы не должны создавать его снова. Вместо этого вы должны найти его на главной форме и нажать кнопку «Редактировать», что вызовет форму frmClient, на которой с помощью кнопки «Новая аренда» точно также присвоите данному клиенту очередную арендованную им технику. На главной форме с помощью поля «Имя клиента» вы можете произвести поиск по базе данных, чтобы найти клиента. По умолчанию поиск происходит по полному совпадению имени, т.е. чтобы найти клиента с именем KH Services, вам необходимо в текстовом поле также полностью ввести его имя, что не всегда бывает удобным. Поэтому в настройках данного текстового поля вы можете изменить режим поиска на частичный, таким образом, вы найдете клиента KH Services даже если в качестве поиска введете просто service. Найдите свойство Filter и выберите его значение %s% как показано на рисунке 51. Рис.51 2.2 Нормализация структуры базы данных. Давайте отдохнем от практики и немного углубимся в теорию, которая поможет нам избежать ошибок, связанных с проектированием структуры базы данных. Поговорим о нормализации базы данных. Если кто-то предпочитает объяснение в академическом стиле, могут подчерпнуть информацию об этом Wikipedia: https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B 0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0 Я же постараюсь объяснить принципы нормализации более простым языком на примерах. Во-первых, нужно понять, зачем нам заниматься нормализацией структуры базы данных. Нормализация это набор правил, которых мы должны придерживаться при создании структуры базы данных. Это поможет нам избежать ошибок в структуре БД, которые могут привести к избыточным или даже противоречивым данным. Сами того не подозревая, но в начале книги мы уже занимались нормализацией, когда рассматривали проблемы хранения данных в одной таблице, и разделяли ее на несколько более маленьких таблиц. Давайте представим, что мы снова ничего не знаем о правилах проектирования баз данных и создали таблицу БД с подобной структурой (рис.52): Рис.52 Приступим к нормализации. Первая нормальная форма Определение первой нормальной формы академическим языком звучит так: Переменная отношения находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов Если говорить простым языком, то в поле не должно быть несколько значений, одно поле = одно значение. В нашем примере обратите внимание на колонку с именем «Хобби», в котором через запятую указаны хобби человека. Это не допустимо, просто запомните это. Чтобы таблица не нарушала это правило, нам придется создать дополнительные записи для каждого хобби человека, т.е. дублируем данные, тем самым намеренно создаем избыточность данных в таблице (рис.53). Рис.53 Избавиться от избыточности данных нам поможет правило второй нормальной формы. Вторая нормальная форма Определение второй нормальной формы академическим языком звучит так: Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от её потенциального ключа. Если простым языком, то у каждой таблицы должен быть первичный ключ, который однозначно идентифицирует запись в таблице. В нашем случае это столбец с именем id, в котором хранится идентификатор записи, он уникален для каждой записи в таблице. Также это правило говорит о том, что в таблице не должно быть дублирующих данных (избыточность). Если вы посмотрите на таблицу (рис.53), которая находится в первой нормальной форме, то увидите, что некоторые записи содержат одинаковые данные, т.е. данные дублируются. Причиной тому столбец «Хобби». Чтобы решить проблему с избыточностью данных, необходимо создать еще одну таблицу, в которой будем хранить хобби персонала, также в таблице будет присутствовать внешний ключ, который будет определять, какому человеку принадлежит указанное хобби. Теперь, когда у нас две таблицы, мы можем создать любое количество хобби, которое может принадлежать человеку, тем самым избежав избыточности данных. Чтобы совсем стало ясно, взгляните на рисунок 54. Рис.54 Если вы используете программу My Visual Database, то при создании таблицы БД, данный первичный ключ всегда создается автоматически. Вам просто не нужно беспокоиться об этом. Третья нормальная форма. Определение третьей нормальной формы академическим языком звучит так: Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых. Третья нормальная форма необходима, чтобы бороться с так называемой транзитивной зависимостью. Для начала разберемся, что это. Обратите внимание, что в таблице персонала (рис.54) имеются столбцы Город и Индекс. К сожалению, людям свойственно ошибаться. Допустим, человек наполняя базу данных, ошибся и ввел сотруднику, живущему в Ярославле Тверской индекс, чему после этого верить? Как результат мы получим противоречивые данные. Таким образом, столбцы Город и Индекс имеют зависимость друг от друга. Но ведь если мы знаем Индекс, мы можем узнать и город по этому индексу. Поэтому, почему бы нам в таблице персонала не хранить только Индекс? Теперь чтобы избавиться от этой транзитивной зависимости, нам необходимо создать еще две таблицы. Таблицу с названиями городов и таблицу с индексами, в которой также будет внешний ключ, определяющий, какому городу принадлежит индекс (рис.55). Рис.55 На практике же не всегда пользуются третьей нормальной формой, оставляя поля с транзитивной зависимостью. Если вы проектируете базу данных, которая будет использоваться, например, в качестве личного справочника, можете пойти на компромисс и оставить все как есть, жертвуя возможным появлением противоречивых данных в угоду простоты. Но если вы проектируете базу данных для использования, например в банковском секторе, на вашем месте я бы не игнорировал третью нормальную форму. Давайте снова взглянем на рисунок 55, так как в таблице Persons есть еще два поля с транзитивной зависимостью. Это поля Зарплата и Налог. Допустим у нас фиксированный налог 13%, поэтому зная зарплату, всегда можно высчитать и налог. Обычно вы не должны хранить данные в таблице, которые могут быть получены из других полей таблицы, поэтому поле Налог можете смело удалить. Как только вы поймете эти правила, они вам покажутся вполне естественными. При дальнейшем проектировании баз данных, вы сами того не заметите как будете придерживаться их совершенно инстинктивно. 2.3. Каскадное удаление и поддержка целостности. Надеюсь, вы не забыли про наш совместный с вами проект по аренде строительной техники. Мы и дальше будем работать с ним, расширяя его функционал, тем самым узнавая, что то новое о базах данных. Запустите My Visual Database и откройте снова наш проект, который находится в папке «Rent project2» . Откройте вкладку «Таблицы базы данных», чтобы видеть созданные таблицы в нашей БД (рис. 56). Рис.56 И поговорим про каскадное удаление. Бывает так, что нам необходимо удалить клиента из базы данных, и все данные, которые связаны с ним. В нашем случае, при удалении клиента (таблица Client) необходимо удалить и все данные об аренде техники данным клиентом (таблица Rent), иначе мы получим записи об аренде, которые ссылаются на несуществующего клиента, что бывает недопустимым. Обратите внимание на внешний ключ id_Client в таблице Rent, который ссылается на клиента из таблицы Client. Для данного внешнего ключа необходимо задействовать так называемое каскадное удаление. После чего, при удалении клиента из таблицы Client, автоматически будут удаляться и записи из таблицы Rent, которые ссылаются на удаляемого клиента благодаря внешнему ключу id_Client. Другими словами, при удалении родительской записи, будут удалены и дочерние записи. Задействовать каскадное удаление для внешнего ключа можно так, как показано на рисунке 57. Рис.57 Честно говоря, без каскадного удаления, вы бы и не смогли удалить клиента из таблицы Client, потому что данный клиент имеет записи об аренде техники. Другими словами, потому что в таблице Rent имеются записи, в которых внешний ключ id_Client ссылается на клиента. Но если вдруг клиент пока не имеет записей об аренде, база данных позволит его удалить, т.к. при этом не нарушается целостность данных в других таблицах. То же самое можно сказать и про внешний ключ id_Equipment в таблице Rent,вы не сможете удалить оборудование из таблицы Equipment, если на данное оборудование ссылается хотя бы одна запись в других таблицах. Таким образом, база данных автоматически поддерживает свою целостность, чтобы не допустить ситуацию, когда внешний ключ ссылается на несуществующую запись. Поэтому, либо вы удаляете запись и все связанные с этой записью данные из БД, используя каскадное удаление, либо не удаляете вовсе. Как правило не принято из базы данных что либо удалять, вместо этого рекомендуется помечать запись как Архив, используя поле с типом «Да/Нет». 2.4. Добавление типа клиента. Продолжаем нашу практику. Давайте сделаем так, чтобы можно было присвоить клиенту его тип, например, является ли он «Физическое лицо» либо «Юридическое лицо». И тут вас может подстерегать ошибка. Есть большой соблазн создать новое текстовое поле в таблице БД «Client», куда бы вы просто вписывали тип клиента. В результате, ваши данные в таблице «Client» выглядели бы, например, так как показано на рисунке 58. Рис.58 Обратите внимание на колонку «Тип клиента», по задумке в этой колонке у нас может быть только два значения, либо «Юридическое лицо», либо «Физическое лицо», таким образом, мы наблюдаем явную избыточность данных, что противоречит второй нормальной форме (глава 2.2). Нет никакого смысла для каждого клиента, вручную, с помощью текста писать его тип. Это недопустимо при проектировании баз данных, т.к. впоследствии это скажется на ее производительности, а также на большую вероятность появления ошибок в БД, например кто-то решит, что достаточно написать просто «Юр. Лицо», или «Ю.Л.», тем самым потеряется целостность данных и сильно усложнится работа с ними. Так как же правильно? Правильным решением, будет создать еще одну таблицу, в которой будут перечислены все допустимые типы клиентов, назовем её «CustomerType». А в таблице «Client» создать внешний ключ, который будет ссылаться таблицу «CutomerType», таким образом, во внешнем ключе будет сохраняться идентификатор выбранного типа клиента. Чтобы стало совсем ясно, взгляните на рисунок 59. Рис.59 При таком подходе, вам не придется каждый раз вручную писать тип клиента, вы просто выберите его из списка. Более того, вы можете добавить в таблицу «CustomerType» новые типы клиентов, например, «Индивидуальный предприниматель», «Гос. предприятие» и т.д. Также ничто не мешает вам переименовывать типы клиентов и это никак не скажется на целостности данных, т.к. во внешнем ключе «id_CustomerType» таблицы «Client» сохраняется лишь числовой идентификатор типа клиента, а не его текстовое представление. С теоретической частью разобрались, теперь опробуем это на практике: 1. Как было сказано выше, нам нужно создать еще одну таблицу в базе данных, назовем ее «CustomerType». 2. В этой таблице необходимо создать колонку с типом ТЕКСТ, назовем ее «TypeName». 3. В таблице «Client», создайте связь с таблицей «CustomerType» В результате у вас должно получиться так, как показано на рисунке 60. Рис.60 Посмотрите на формы |