Lesson 06.01 Working With SQL

download Lesson 06.01 Working With SQL

of 33

  • date post

    13-Sep-2015
  • Category

    Documents

  • view

    1
  • download

    0

Embed Size (px)

description

Lesson 06.01 Working With SQL

Transcript of Lesson 06.01 Working With SQL

  • ADVANCED ANDROID

    DEVELOPMENTLesson 6.01 Working with SQL and SQLite

  • SQLiteIt is typical for applications to store data in a relational database. A database is very efficient at working with different types of data, and is able to quickly recall that data as it becomes necessary.

    Android provides SQLite database engine for us to work with.

    "SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain."

    http://www.sqlite.org/

  • DatabasesBefore we get down to the details about how SQLite actually works, lets take a step back, and look at databases in general.

    A database is really nothing more than a well organized storage facility for your data. Everyone, at

    one time or another, or on a regular basis, uses databases, and may not even know it.

    For example, Google search engine, is a large database of web sites. Your address book maintained by your email program, is a database. A checkbook manager that helps you balance your finances, is a database. And even the television schedule that you retrieve on your DVR or cable box is a database.

  • DatabaseThink of a database as a file cabinet.

    A well organized file cabinet will have sections for different types of files. For example, you may have a set of files about your authors in the top drawer. A set of files about the books they wrote in the middle drawer, and a set of publishers who published those books for those authors in the third drawer.

    The problem with the file cabinet though is that its not easy to quickly identify all of the books that were written in a specific year, or identify all of the publishers used by a particular author. For that matter, you'd have to do some digging in order to find all of the books that an author wrote throughout his or her career. These are typicaly queries that are easily addressed with a well managed database.

  • Tables and FieldsIn the file cabinet from our previous slide, you have a drawer for each of your three main categories:

    Authors, Titles, and Publishers.

    In a relational database, you would have three tables, each one containing information about a

    specific category, such as authors, titles, and publishers.

    In the file cabinet, each drawer would contain multiple files, each one with information about a specific person, book, or publisher. In a database table, you would have rows of data, each row specific to a person, book or publisher.

    Each row of data in a table is further broken down into fields. A field is similar to a variable. It holds a single piece of information of a certain data type. Fields can be numeric, string, boolean, date or time, or even binary.

  • Relationships

    The easiest way to describe the relationship between Authors, Titles, and Publishers is with the above database "schema". A schema is a database diagram, or representation.

    In the Authors table, we are storing the name and year of birth for the author. Each author is assigned a unique identifier called Au_ID. That identifier is used in in the Title Authors table to associate one or more book ISBN numbers to an author in my Authors table. The ISBN is also a unique identifier, and joins to the Titles table, where each book is described. Finally, the Publishers table joins to the Titles table in order to establish the relationship between the publisher and the books they released to market.

  • Primary KeysThose unique identifiers I mentioned before, are known as primary keys. They are always unique. Even if a record is deleted from a database, the deleted primary key will never be introduced back into the database naturally. You can certainly, re-create the deleted record manually.

    The primary keys, and the relationships defined between tables, help keep data integrity, consistency, and makes it easily searchable. Deleting an author would require you to also delete all of the books that the author wrote (unless co-authored), as an example.

  • TableFields

    Rows of Data (a Record)

  • Designing a SchemaThe first step, when building your new database, is to review and organize your data into categories. While reviewing your data, look for ways to minimize data redundancy. Duplicate data in multiple tables is wasteful, and is difficult to maintain. The art of removing duplicate information and replacing it with a relationship instead is known as normalization.

  • Table RelationshipsThere are several different types of relationships that can be set up between database tables.

    A relationship represents how a table is able to locate related information in another table within your database. The basic relationships are:

    One To One This means that one record in Table A has one record of related information available in Table B.

    One To Many Table A has one record, but Table B has multiple records that relate the record in A.

    Many To Many Multiple records in Table A can relate to multiple records in Table B.

    Alternatively, data can stand on its own, and it isnt always necessary for a table to have a relationship with another table.

    This classification of the number of records that can exist on each side of the relationship is known as the "Cardinality".

  • One To One RelationshipIn this cardinality, one customer can have only one credit limit. This is a one to one relationship.

    Customer # Name Address Phone

    12345 Test Person 123 Main Street 555-1212

    12346 Another Person 44 Main Street 555-1111

    12347 Last Person 55 Main Street 555-1010

    Credit ID Customer # Credit Limit

    7 12345 $500

    8 12346 $1,000

    9 12347 500.00$

    Table A

    Table B

  • One To Many RelationshipA single customer (A) relates to multiple invoices (B).

    Customer # Name Address Phone

    12345 Test Person 123 Main Street 555-1212

    12346 Another Person 44 Main Street 555-1111

    12347 Last Person 55 Main Street 555-1010

    Table A

    Invoice # Customer # Amount

    3 12345 $299

    4 12345 $199

    5 12347 $399

    Table B

  • Many To Many RelationshipIn a many to many relationship, many records in one table can apply to records in another table. In the above example, Customer 12345 has a Visa and a Mastercard, while Customer 12346 has only an American Express card, and Customer 12347 has American Express and Mastercard. You can see that in order to create this relationship, a third table (called a "Junction" table) is introduced that stores keys from the other two.

    Customer # Name Address Phone

    12345 Test Person 123 Main Street 555-1212

    12346 Another Person 44 Main Street 555-1111

    12347 Last Person 55 Main Street 555-1010

    Customer # Credit Card ID

    12345 1

    12346 3

    12347 2

    12345 2

    12347 3

    Credit Card ID Type

    1 Visa

    2 Mastercard

    3 American Express

  • JoinsThere are several different ways of joining tables together using SQLite T-SQL queries.

    Inner Join allows you to select records from two or more tables where ONLY the matching records are returned. So if you have a Customer and Invoice table, and there are more customers than invoices, only records for customers who have invoices will be returned.

    Outer Join An outer join allows you to look at data in both tables. An outer join will return records that match, but also return records from the table you joined to that do not match. So, again, with Customers and Invoices, an outer join would return everything that the Inner join did, but in addition to that it would return the remaining customers, with no information for the invoice portion of your result set.

    As we build tables, and views, joins and their usage will become more apparent.

  • Database ManagersThere are a number of free, and paid applications that can be used to manage your SQLite database.

    NaviCat - http://www.navicat.com/ - This is a premium database management tool, which supports

    many different databases, not just SQLite. I use it with MySQL, SQLite, and SQL Server. Windows only.

    SQLite Admin - http://sqliteadmin.orbmu2k.de/ - This is a Windows only utility. Free.

    SQLite Manager - http://www.sqlabs.com/sqlitemanager.php - Windows and OS X friendly, but not free.

    SQLite Manager https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/ - This is a free Firefox add-on. It works across Windows, OS X, and Linux, and the utility we'll be using in this class.

  • Getting StartedUsing Firefox, download and install the SQLite Manager v0.77 (or higher).

    After the installation, the tool will become available in your Firefox menu, under Web Developer.

  • SQLite ManagerOnce you open SQLite Manager, you can close Firefox.

    To create a new database, select Database, then New Database. Give it a path and filename.

  • Building TablesOnce you have a database created, you can add tables. To do so, right-click over the Tables node, and select Create Table. You can also use the Create Table icon in the SQLite Manager toolbar.

  • Supported Data TypesThe fields that you define within your table has to be of a specific type. For example, a field can be a string of text, or a date, or a currency value, or just a number.

    SQLite doesnt support many data types, and in fact, you can define a field as being numeric, and it would be perfectly OK with the database to store some text there instead. SQLite allows you define a data type, but it is on